It is not unusual for code produced by Mac F2C to compile without any problems, but crash and burn when run. In fact, if you get to the ccommand() dialog (the one that asks you to set up standard input and standard output), but crash immediately there after, it is almost certain that you are blowing out the stack space. The problem and its solution are described below.
The problem arises because FORTRAN allocates memory for all its variables statically. The C code produced by Mac F2C by default uses automatic storage for most variables. On the Macintosh automatic variables get stored on the stack. When the FORTRAN code declares large arrays (quite common in FORTRAN code), these become large arrays on the stack in the C version. Because less than 24K is normally allocated as stack space by default on the Macintosh, your program blows out the stack.
There are two 窶徠uick窶 fixes to this problem which usually work (either separately or in combination). There is also a more tedious, but 100% reliable fix that involves modifying the code generated by Mac F2C. All three of these fixes are described below.
Quick Fix 1: Use Static Storage
The first quick fix to try is to translate the FORTRAN code with the Make local variables automatic vice static option in the C Output options dialog unchecked. This will move all of the large arrays from the stack to the global data space. You should also increase the memory partition for your program (either in the Finder窶冱 Get Info dialog if it is a free-standing application, or in the appropriate THINK, Symantec, or CodeWarrior dialog if it is under development) to allow for the extra memory required by the large global arrays.
This 窶彷ix窶 will often solve the problem. However, because some C/C++ compilers still impose a 32K limit on the amount of global data per file, you can still have problems with files that have too many large arrays in them. If you are lucky, you can divide the file somehow so that the arrays are split among several files and now don窶冲 violate the 32K/file limit. However, that might not be possible if, for example, all the arrays appear within a single subroutine. If not, try 窶弉uick Fix 2窶 or the 窶弋rue but Tedious Fix窶 described below.
Quick Fix 2: Enlarge the Stack
Both F2CMain.c and F2CMain.cp contain code that adjusts the size of the stack when generating 68K code. You can simply modify a single line in these files to adjust the stack size to whatever you need.
If you are generating PPC code, then you can set the stack size to anything you need by modifying the PEF, but I don窶冲 have a PowerMac, so I don窶冲 know how you would do this. Sorry.
To change the stack size when generating 68K code, open either F2CMain.c or F2CMain.cp, as appropriate, and search for the following segement of code:
#define kDesiredStackSize (40*1024L) /* 68K stack size set to 40K bytes */
The key line is the one that defines kDesiredStackSize. It is currently set to 40KB. If you want to make the stack 200KB, simply edit the line, changing the 40 to 200, so the line now reads:
#define kDesiredStackSize (200*1024L) /* 68K stack size set to 200K bytes */
After making the change, simply rebuild your executable and give it a try. It窶冱 hard to determine the correct stack size. You can scan your source code and add up the size of the big arrays to get a rough estimate. In any case, some trial-and-error will be required. If you increase the stack size significantly, remember also to increase the memory partition for your program by a corresponding amount.
The 窶彿ncrease the stack size窶 fix should generally work. If it doesn窶冲, you can modify the code generated by Mac F2C to move the memory allocations from the stack to the heap (i.e., from automatic to dynamic allocation). How to do this is described in the next section.
True but Tedious Fix: Allocate Memory Dynamically
If all else fails, the only solution is to edit the C code so that it allocates the memory dynamically.
Let窶冱 work an example. Consider the following simple FORTRAN program:
program example
double precision d
dimension a(100,100), b(100,200,20)
dimension d(50,20,10)
a(100,100) = 1.0
b(100,200,20) = 1.0
d(50,20,10) = 1.0d0
stop
end
Basically all it does is allocate three arrays. Note that the arrays are not that large by FORTRAN standards. Selecting the option that allocates local variables automatically, this program translates into:
/* JUNK.f -- translated by f2c (version 19941113).
You must link the resulting object file with the libraries:
-lf2c -lm (in that order)
*/
#include "f2c.h"
/* Main program */ MAIN__(void)
{
/* Builtin functions */
/* Subroutine */ int s_stop(char *, ftnlen);
/* Local variables */
real a[10000] /* was [100][100] */, b[400000] /* was [100][200][20]
*/;
doublereal d[10000] /* was [50][20][10] */;
a[9999] = 1.f;
b[399999] = 1.f;
d[9999] = 1.;
s_stop("", 0L);
return 0;
} /* MAIN__ */
/* Main program alias */ int example_ () { MAIN__ (); return 0; }
Note how in the C version 410,000 reals and 10,000 doublereals are allocated on the stack窶杯hat窶冱 over 1.5MB on the stack. Your program will crash the moment it enters the MAIN__() function. If you tried using static vice automatic variables you would have over 32K of global data in one file and it wouldn窶冲 build under THINK C.
Multi-dimensional arrays can be quite large even when their individual dimensions are small. It窶冱 easy to blow out the stack or the THINK C limit on global data per file with even one or two arrays of three or more dimensions. I窶况e also seen programs get into problems because they have lots of small arrays.
The solution is to replace the array variables with pointers and allocate the memory for them using malloc() or any of its cousins. Because C treats pointers and arrays similarly, the rest of the code works without any changes.
Applying this technique to the example yields the following modified code:
/* JUNK.f -- translated by f2c (version 19941113).
You must link the resulting object file with the libraries:
-lf2c -lm (in that order)
*/
#include "f2c.h"
#define NEW_CODE /* <======== to make the changes clear */
#ifdef NEW_CODE
#include <stdlib.h> /* Get prototypes for malloc(), etc */
#endif
/* Main program */ MAIN__(void)
{
/* Builtin functions */
/* Subroutine */ int s_stop(char *, ftnlen);
/* Local variables */
#ifdef NEW_CODE
real *a, *b; /* Pointers instead of arrays */
doublereal *d;
#else
real a[10000] /* was [100][100] */, b[400000] /* was [100][200][20]
*/;
doublereal d[10000] /* was [50][20][10] */;
#endif
#ifdef NEW_CODE /* allocate the memory */
a = (real *) malloc( 10000*sizeof(real) );
b = (real *) malloc( 400000*sizeof(real) );
d = (doublereal *) malloc( 10000*sizeof(doublereal) );
/* Remember to check a, b, and d for NULL (e.g., out of memory) */
#endif
a[9999] = 1.f;
b[399999] = 1.f;
d[9999] = 1.;
#ifdef NEW_CODE
free( a ); /* Don't forget to free the memory */
free( b );
free( d );
#endif
s_stop("", 0L);
return 0;
} /* MAIN__ */
/* Main program alias */ int example_ () { MAIN__ (); return 0; }
This version of the program will work fine so long as there is enough heap space to allocate the memory requested in the malloc() calls. You can add more heap space by simply increasing the partition size of the program (either in the Finder窶冱 Get Info dialog if it is a free-standing application, or in the appropriate THINK, Symantec, or CodeWarrior dialog if the code is under development).
This modified version will also work if the variables a, b, and d had been declared static vice automatic.
